\documentclass{beamer}

\usetheme{CambridgeUS}
%\usecolortheme{lily} 
%\setbeamercolor{frametitle}{bg=blue,fg=yellow} 
%\beamersetaveragebackground{blue!10} 

\newcommand{\supp}{\textrm{{s}upp}
}
\newcommand{\ce}{\mbox{\textnormal{{c}e}}
}
\newcommand{\card}{\mbox{\textnormal{{c}ard}}
}
\newcommand{\rc}{\mbox{\textnormal{rc}}
}
\newcommand{\sig}{\textrm{$\Sigma$Count}
}
\newcommand{\nf}{\mbox{\textnormal{nf$\sigma$-count}}
}
\newcommand{\req}[1]{(\ref{#1})}
\newcommand{\inn}{\mbox{\textnormal{in}}
}
\newcommand{\clm}{\mbox{\textnormal{clm}}
}

%\usepackage{polski}
%\usepackage[polish]{babel}
%\usepackage[T1]{fontenc}
%{{{
\usepackage[utf8]{inputenc}
\usepackage{amssymb}
\usepackage{graphicx} %for eps graphics
\usepackage{txfonts}
\usepackage{array}
\usepackage{graphicx}
\usepackage{url}
%}}}

\title{SELinux in typical applications.}
%\toctitle{Lingwistyczne podsumowania baz danych.Inteligentne\ldots}

\author{Adam Taciak and Łukasz Kucharczyk}
%\institute{Zakład Sieci Komputerowych, Politechnika Łódzka}
\date{April 18, 2012}

%\begin{frame}{\tableofcontents[currentsection]}
%\begin{frame}{\tableofcontents[currentsubsection]}

\begin{document}

\maketitle

\begin{frame}{Agenda}

\begin{itemize}
  \item Introduction to SELinux
  \item Access Control Mechanisms
  \item Example
  \item Summary
\end{itemize}

\end{frame}

%---------------------new section------------------------------------
\section{Introduction}

\begin{frame}{Meaning of SELinux}
\begin{center}
  SELinux is abbreviation for \textbf{S}ecurity-\textbf{E}nhanced \textbf{Linux}.
\end{center}
\end{frame}

\begin{frame}{What is SELinux?}
  \begin{block}{}
    SELinux is an implementation of mandatory access controls (MAC) on Linux. Mandatory access controls allow an administrator of a system to define how applications and users can access different resources such as files, devices, networks and inter-process communication. 
  \end{block}
\end{frame}

\begin{frame}{Brief Background}
SELinux was originally a development project from the National Security Agency (NSA) and others. It is an implementation of the Flask operating system security architecture. The NSA integrated SELinux into the Linux kernel using the Linux Security Modules (LSM) framework. SELinux motivated the creation of LSM, at the suggestion of Linus Torvalds, who wanted a modular approach to security instead of just accepting SELinux into the kernel.
\end{frame}

%---------------------new section------------------------------------
\section{Access Control Mechanisms}

\begin{frame}{Access Control Mechanisms in SELinux}
  \begin{itemize}
    \item Discretionary Access Control (DAC)
    \item Access Control List (ACL)
    \item Mandatory Access Control (MAC)
    \item Role-based Access Control (RBAC)
  \end{itemize}
\end{frame}

\begin{frame}{Discretionary Access Control}
\begin{block}{}
		Discretionary Access Control (DAC) defines the basic access controls for objects in a filesystem. This is the typical access control provided by file permissions, sharing, etc. Such access is generally at the discretion of the owner of the object (file, directory, device, etc.).\\
\end{block}

\begin{block}{}
	DAC provides a means of restricting access to objects based on the identity of the users or groups (subjects) that try to access those objects. Depending on a subject's access permissions, they may also be able to pass permissions to other subjects.
\end{block}
\end{frame}

\begin{frame}{Access Control Lists}
  Access Control Lists (ACL) is a complementary mechanism model of the DAC. ACL is the addition of new classes of access and rights of access to the object, depending on certain aspects of the process of asking for access. As in the DAC is defined in the schema UGO permissions, the ACL so we can extend the definition of rights to certain users or groups.
\end{frame}

\begin{frame}{Mandatory Access Control}
\begin{block}{}
	Mandatory Access Control (MAC) is a security mechanism that restricts the level of control that users (subjects) have over the objects that they create. Unlike in a DAC implementation, where users have full control over their own files, directories, etc., MAC adds additional labels, or categories, to all file system objects. Users and processes must have the appropriate access to these categories before they can interact with these objects.
\end{block}
\end{frame}

\begin{frame}{Role-based Access Control}
\begin{block}{}
	Role-based Access Control (RBAC) is an alternative method of controlling user access to file system objects. Instead of access being controlled by user permissions, the system administrator establishes Roles based on business functional requirements or similar criteria. These Roles have different types and levels of access to objects.
\end{block}
\begin{block}{}
In contrast to DAC or MAC systems, where users have access to objects based on their own and the object's permissions, users in an RBAC system must be members of the appropriate group, or Role, before they can interact with files, directories, devices, etc.
\end{block}
\end{frame}

\begin{frame}{Comparison Access Control Mechanisms}
\begin{table}
\begin{tabular}{|p{1.2cm}|p{1.8cm}|p{2cm}|p{2cm}|p{2.5cm}|}
\hline 
Client Server & Complexity & Goal & Limitations & Benefits \\ 
\hline 
{\tiny DAC }& {\tiny Low} & {\tiny Limit acces to system files} & {\tiny Administrator has access to everything }& {\tiny Standard file permissions on Windows and UNIX }\\ 
\hline 
{\tiny MAC} & {\tiny Hight} & {\tiny Limit access to objects by security clearence labels} & {\tiny Requires a lot of planning} & {\tiny No one user of a lesser clearance may read an object of a greater clearance.

No one subject of a greater clearance may write to an object of a lesser clearance} \\ 
\hline 
{\tiny RBAC }& {\tiny Hight} & {\tiny Limit systems use and transacations by pre-defined job roles} & {\tiny Great administrative Overhead Requries dedicated expertise on site Time intensive} & {\tiny Can prevent fraud in Banks.
Limits the “Area of potential destruction” that an unwitting subject may engage in. }\\ 
\hline 
\end{tabular} 
\end{table}
\end{frame}

\begin{frame}{FLASK}
%SELinux jest systemem implementującym architekturę FLASK, a co za tym idzie realizuje on politykę MAC. Realizowane jest to przy użyciu wybranych modeli bezpieczeństwa. Implementacja przykładowego serwera bezpieczeństwa dla SELinux bazuje na modelu bezpieczeństwa będącym połączeniem modeli RBAC,TE i MLS. SELinux utrzymuje tzw. kontekst bezpieczeństwa składający się z trzech atrybutów bezpieczeństwa: tożsamości, roli i typu. Przy obliczaniu zbioru decyzji dostępu używany jest każdy z trzech składników kontekstu bezpieczeństwa.
FLASK (Flux advanced Security Kernel) is an operating system security architecture that addresses the
need of flexibility in security policies. Flask was developed to address three key security policy
requirements.

\begin{enumerate}
  \item Controlling the propagation of access rights.
  \item Enforcing fine grained access rights.
  \item Supporting the revocation of previously granted access rights.
\end{enumerate}
\end{frame}

\begin{frame}{Architecture of FLASK}
The three key elements of flask architecture are a object manager, security server and Access Vector
Cache (AVC).
\begin{enumerate}
  \item Object Manager is the enforcer of the security policy.
  \item Security server is responsible for making security decisions.
  \item Access vector cache is speeds up policy lookup decisions.
\end{enumerate}
\end{frame}

%\begin{frame}{The SELinux Decision Making Process}
%\begin{block}{}
%When a subject, (for example, an application), attempts to access an object (for example, a file), the policy enforcement server in the kernel checks an access vector cache (AVC), where %subject and object permissions are cached. If a decision cannot be made based on data in the AVC, the request continues to the security server, which looks up the security context of the application and the file in a matrix. Permission is then granted or denied, with an avc: denied message detailed in /var/log/messages if permission is denied. The security context of subjects and objects is applied from the installed policy, which also provides the information to populate the security server's matrix.
%\end{block}
%\end{frame}

\begin{frame}{The SELinux Decision Making Process}
\begin{center}
\begin{figure}
	\includegraphics[scale=0.5]{SELinux_Decision_Process.png} 
	\caption{Scheme of making decision}
\end{figure}
\end{center}
\end{frame}

\begin{frame}{Architecture of SELinux}
SELinux being an implementation of Flask, it relies on security contexts for labeling of subjects and
objects. Everything that can be a subject (namely a process) has a security context associated to it, and
so does everything that can be accessed as a resource (namely via file handle). 
\end{frame}

\begin{frame}{Architecture of SELinux}
\begin{center}
\begin{figure}
	\includegraphics[scale=0.3]{SELinux_Architecture.png} 
	\caption{Security Context usage in SELinux}
\end{figure}
\end{center}
%In Figure 7, subjects requesting access to an object do so through the mediation of the Security
%Enforcement Module. This in turn enforces security policies when accessing objects on the subjects’
%behalf. The Security Context of each participant (as well as the SIDs) is used as input for policy
%evaluation and enforcement.
\end{frame}


%---------------------new section------------------------------------
\section{Example}

\begin{frame}[containsverbatim]{Example}
Configuration of insmod:
  %\begin{block}{}
    \begin{verbatim}
allow sysadm_t insmod_exec_t:file x_file_perms;
allow sysadm_t insmod_t:process transition;
allow insmod_t insmod_exec_t:process { entrypoint execute };
allow insmod_t sysadm_t:fd inherit_fd_perms;
allow insmod_t self:capability sys_module;
allow insmod_t sysadm_t:process sigchld;
    \end{verbatim}
  %\end{block}
\end{frame}

\begin{frame}
\texttt{allow sysadm\_t insmod\_exec\_t:file x\_file\_perms;} \\
%pozwolenie domenie sysadm\_t na wykonywanie programu insmod \\
allows domain sysadm\_t to execute program insmod \\
\pause
\texttt{allow sysadm\_t insmod\_t:process transition;} \\
%pozwolenie na przejście z domeny sysadm\_t do domeny insmod\_t \\
allows to change domain from sysadm\_t to insmod\_t \\
\pause
\texttt{allow insmod\_t insmod\_exec\_t:process \{ entrypoint execute \};} \\
%pozwolenie na wejście programowi insmod do domeny insmod\_t i wykonanie kodu insmod w tej domenie \\
allows insmod to enter to insmod\_t domain and execute it in this domain \\
\pause
\texttt{allow insmod\_t sysadm\_t:fd inherit\_fd\_perms;} \\
%pozwolenie na odziedziczenie i uzycie przez domene insmod\_t deskryptorow plikow.
allows to inherit and use by insmod\_t domain system file descriptors \\
\pause
\texttt{allow insmod\_t self:capability sys\_module;} \\
%pozwolenie domenie insmod\_t na uzycie sys\_module
allows insmod\_t domain to use sys\_module \\
\pause
\texttt{allow insmod\_t sysadm\_t:process sigchld;} \\
%pozwolenie insmod\_t na wyslanie sygnalu SIGCHILD do sysadm\_t
allows insmod\_t to send SIGCHILD signal to sysadm\_t \\
\end{frame}

\begin{frame}{Example :: summary}
  \begin{itemize}
    \item Flexibility 
    \item Complex configuration
    \item Difficulties during polices verification
    \item Default configuration has been created
  \end{itemize}
\end{frame}

%---------------------new section------------------------------------
\section{Summary}

\begin{frame}{Conclusion}
SELinux can not only protect users from viruses, Trojans and other malwares (at no extra cost) but also from bugs in applications especially web applications. The websites and web applications we use normally come in thousands of line of code. Without knowing what those thousands of lines of codes do there is no other way to know if an application will really do what you tell it or it becomes malicious due to vulnerabilities.
\end{frame}

\begin{frame}{Bibliography}
  \begin{itemize}
    \item \url{http://www.nsa.gov/research/selinux/index.shtml}
    \item Official SELinux project page: \url{http://www.selinuxproject.org}
    \item Red Hat Enterprise Linux Deployment Guide: \url{http://www.centos.org/docs/5/html/Deployment_Guide-en-US/index.html}
    \item \url{http://itsecurityideas.blogspot.com/2011/05/dac.html}
    \item ,,Flask: Flux Advanced Security Kernel'', dr. Richard Stanley
  \end{itemize}
\end{frame}

\begin{frame}
  \begin{center}
    \Huge Thank you for your attention!
  \end{center}
\end{frame}


\end{document}
